Глава 7: Multi-Agent Collaboration
Хотя архитектура монолитного агента может быть эффективной для четко определенных задач, её возможности часто ограничены при столкновении со сложными многодоменными задачами. Паттерн Multi-Agent Collaboration решает эти ограничения путем структурирования системы как кооперативного ансамбля отдельных специализированных агентов. Этот подход основан на принципе декомпозиции задач, где высокоуровневая цель разбивается на дискретные подзадачи. Каждая подзадача затем назначается агенту, обладающему специфическими инструментами, доступом к данным или способностями к рассуждению, наиболее подходящими для этой задачи.
Например, сложный исследовательский запрос может быть декомпозирован и назначен Research Agent для извлечения информации, Data Analysis Agent для статистической обработки и Synthesis Agent для генерации итогового отчета. Эффективность такой системы обусловлена не только разделением труда, но и критически зависит от механизмов межагентной коммуникации. Это требует стандартизированного протокола коммуникации и общей онтологии, позволяющих агентам обмениваться данными, делегировать подзадачи и координировать свои действия для обеспечения согласованности итогового результата.
Эта распределенная архитектура предлагает несколько преимуществ, включая повышенную модульность, масштабируемость и надежность, поскольку отказ одного агента не обязательно приводит к полному отказу системы. Сотрудничество позволяет достичь синергетического результата, где коллективная производительность многоагентной системы превосходит потенциальные возможности любого отдельного агента в ансамбле.
Обзор паттерна Multi-Agent Collaboration
Паттерн Multi-Agent Collaboration включает проектирование систем, где множественные независимые или полунезависимые агенты работают вместе для достижения общей цели. Каждый агент обычно имеет определенную роль, специфические цели, выровненные с общей задачей, и потенциально доступ к различным инструментам или базам знаний. Сила этого паттерна заключается во взаимодействии и синергии между этими агентами.
Сотрудничество может принимать различные формы:
- Последовательные передачи: Один агент завершает задачу и передает свой результат другому агенту для следующего шага в конвейере (аналогично паттерну Planning, но явно включающему разных агентов).
- Параллельная обработка: Множественные агенты работают над разными частями проблемы одновременно, и их результаты позже объединяются.
- Дебаты и консенсус: Multi-Agent Collaboration, где агенты с различными перспективами и источниками информации участвуют в дискуссиях для оценки вариантов, в конечном итоге достигая консенсуса или более информированного решения.
- Иерархические структуры: Агент-менеджер может динамически делегировать задачи рабочим агентам на основе их доступа к инструментам или возможностей плагинов и синтезировать их результаты. Каждый агент также может обрабатывать соответствующие группы инструментов, а не один агент, обрабатывающий все инструменты.
- Экспертные команды: Агенты со специализированными знаниями в различных доменах (например, исследователь, писатель, редактор) сотрудничают для создания сложного результата.
- Критик-рецензент: Агенты создают первоначальные результаты, такие как планы, черновики или ответы. Вторая группа агентов затем критически оценивает этот результат на соответствие политикам, безопасности, соблюдению требований, корректности, качеству и выравниванию с организационными целями. Первоначальный создатель или финальный агент пересматривает результат на основе этой обратной связи. Этот паттерн особенно эффективен для генерации кода, написания исследований, проверки логики и обеспечения этического выравнивания. Преимущества этого подхода включают повышенную надежность, улучшенное качество и сниженную вероятность галлюцинаций или ошибок.
Многоагентная система (см. Рис.1) фундаментально включает определение ролей и обязанностей агентов, установление каналов коммуникации, через которые агенты обмениваются информацией, и формулировку потока задач или протокола взаимодействия, который направляет их совместные усилия.
Рис.1: Пример многоагентной системы
Фреймворки, такие как Crew AI и Google ADK, разработаны для облегчения этой парадигмы, предоставляя структуры для спецификации агентов, задач и их интерактивных процедур. Этот подход особенно эффективен для вызовов, требующих разнообразных специализированных знаний, охватывающих множественные дискретные фазы или использующих преимущества параллельной обработки и подтверждения информации между агентами.
Практические применения и случаи использования
Multi-Agent Collaboration является мощным паттерном, применимым в многочисленных доменах:
Комплексные исследования и анализ: Команда агентов может сотрудничать над исследовательским проектом. Один агент может специализироваться на поиске в академических базах данных, другой на резюмировании находок, третий на выявлении трендов, а четвертый на синтезе информации в отчет. Это отражает то, как может работать человеческая исследовательская команда.
Разработка программного обеспечения: Представьте агентов, сотрудничающих в создании программного обеспечения. Один агент может быть аналитиком требований, другой генератором кода, третий тестировщиком, а четвертый автором документации. Они могут передавать результаты между собой для создания и проверки компонентов.
Генерация креативного контента: Создание маркетинговой кампании может включать агента исследования рынка, агента-копирайтера, агента графического дизайна (использующего инструменты генерации изображений) и агента планирования в социальных сетях, работающих вместе.
Финансовый анализ: Многоагентная система может анализировать финансовые рынки. Агенты могут специализироваться на получении данных о акциях, анализе настроений новостей, выполнении технического анализа и генерации инвестиционных рекомендаций.
Эскалация клиентской поддержки: Агент первой линии поддержки может обрабатывать первоначальные запросы, эскалируя сложные вопросы специалисту-агенту (например, техническому эксперту или специалисту по биллингу) при необходимости, демонстрируя последовательную передачу на основе сложности проблемы.
Оптимизация цепи поставок: Агенты могут представлять различные узлы в цепи поставок (поставщики, производители, дистрибьюторы) и сотрудничать для оптимизации уровней запасов, логистики и планирования в ответ на изменяющийся спрос или сбои.
Анализ сети и восстановление: Автономные операции значительно выигрывают от агентной архитектуры, особенно в точном определении сбоев. Множественные агенты могут сотрудничать для сортировки и восстановления проблем, предлагая оптимальные действия. Эти агенты также могут интегрироваться с традиционными моделями машинного обучения и инструментарием, используя существующие системы и одновременно предлагая преимущества Generative AI.
Способность определять специализированных агентов и тщательно оркестрировать их взаимосвязи позволяет разработчикам создавать системы с повышенной модульностью, масштабируемостью и способностью решать сложности, которые были бы непреодолимы для единственного интегрированного агента.
Multi-Agent Collaboration: Исследование взаимосвязей и структур коммуникации
Понимание сложных способов взаимодействия и коммуникации агентов является фундаментальным для проектирования эффективных многоагентных систем. Как показано на Рис. 2, существует спектр моделей взаимосвязей и коммуникации, от простейшего сценария с одним агентом до сложных, специально разработанных коллаборативных фреймворков. Каждая модель представляет уникальные преимущества и вызовы, влияющие на общую эффективность, надежность и адаптивность многоагентной системы.
1. Единичный Agent: На самом базовом уровне "Единичный Agent" действует автономно без прямого взаимодействия или коммуникации с другими сущностями. Хотя эта модель проста в реализации и управлении, её возможности изначально ограничены областью и ресурсами отдельного агента. Она подходит для задач, которые можно декомпозировать на независимые подзадачи, каждая из которых решается одним самодостаточным агентом.
2. Network: Модель "Network" представляет значительный шаг к сотрудничеству, где множественные агенты взаимодействуют друг с другом децентрализованным образом. Коммуникация обычно происходит по принципу peer-to-peer, позволяя обмениваться информацией, ресурсами и даже задачами. Эта модель способствует устойчивости, поскольку отказ одного агента не обязательно парализует всю систему. Однако управление накладными расходами на коммуникацию и обеспечение согласованного принятия решений в большой неструктурированной сети может быть сложным.
3. Supervisor: В модели "Supervisor" выделенный агент, "супервизор", контролирует и координирует деятельность группы подчиненных агентов. Супервизор действует как центральный узел для коммуникации, распределения задач и разрешения конфликтов. Эта иерархическая структура предлагает четкие линии власти и может упростить управление и контроль. Однако она вводит единую точку отказа (супервизор) и может стать узким местом, если супервизор перегружен большим количеством подчиненных или сложными задачами.
4. Supervisor as a Tool: Эта модель является нюансированным расширением концепции "Supervisor", где роль супервизора менее связана с прямым командованием и контролем и больше с предоставлением ресурсов, руководства или аналитической поддержки другим агентам. Супервизор может предлагать инструменты, данные или вычислительные сервисы, которые позволяют другим агентам более эффективно выполнять свои задачи, не обязательно диктуя каждое их действие. Этот подход направлен на использование возможностей супервизора без наложения жесткого контроля сверху вниз.
5. Hierarchical: Модель "Hierarchical" расширяет концепцию супервизора для создания многоуровневой организационной структуры. Это включает множественные уровни супервизоров, где супервизоры высокого уровня контролируют супервизоров низкого уровня и, в конечном итоге, коллекцию операционных агентов на самом низком уровне. Эта структура хорошо подходит для сложных проблем, которые можно декомпозировать на подзадачи, каждая из которых управляется специфическим уровнем иерархии. Она предоставляет структурированный подход к управлению масштабируемостью и сложностью, позволяя распределенное принятие решений в определенных границах.
Рис. 2: Агенты коммуницируют и взаимодействуют различными способами.
6. Custom: Модель "Custom" представляет максимальную гибкость в проектировании многоагентных систем. Она позволяет создание уникальных структур взаимосвязей и коммуникации, точно адаптированных к специфическим требованиям данной проблемы или приложения. Это может включать гибридные подходы, которые объединяют элементы из ранее упомянутых моделей, или полностью новые дизайны, возникающие из уникальных ограничений и возможностей среды. Кастомные модели часто возникают из необходимости оптимизации для специфических метрик производительности, обработки высокодинамичных сред или включения доменно-специфических знаний в архитектуру системы. Проектирование и реализация кастомных моделей обычно требует глубокого понимания принципов многоагентных систем и тщательного рассмотрения протоколов коммуникации, механизмов координации и эмерджентного поведения.
В заключение, выбор модели взаимосвязей и коммуникации для многоагентной системы является критическим проектным решением. Каждая модель предлагает отличные преимущества и недостатки, и оптимальный выбор зависит от таких факторов, как сложность задачи, количество агентов, желаемый уровень автономии, потребность в надежности и приемлемые накладные расходы на коммуникацию. Будущие достижения в многоагентных системах, вероятно, продолжат исследовать и совершенствовать эти модели, а также разрабатывать новые парадигмы для коллаборативного интеллекта.
Практический код (Crew AI)
Этот Python код определяет AI-powered команду, использующую фреймворк CrewAI для генерации блог-поста о трендах AI. Он начинается с настройки окружения, загрузки API ключей из .env файла. Ядро приложения включает определение двух агентов: исследователя для поиска и резюмирования трендов AI, и писателя для создания блог-поста на основе исследования.
Соответственно определяются две задачи: одна для исследования трендов и другая для написания блог-поста, где задача написания зависит от результата задачи исследования. Эти агенты и задачи затем объединяются в Crew, указывающую последовательный процесс, где задачи выполняются по порядку. Crew инициализируется с агентами, задачами и языковой моделью (конкретно модель "gemini-2.0-flash"). Главная функция выполняет эту команду, используя метод kickoff(), оркестрируя сотрудничество между агентами для производства желаемого результата. Наконец, код выводит финальный результат выполнения команды, который является сгенерированным блог-постом.
import os
from dotenv import load_dotenv
from crewai import Agent, Task, Crew, Process
from langchain_google_genai import ChatGoogleGenerativeAI
def setup_environment():
"""Загружает переменные окружения и проверяет наличие требуемого API ключа."""
load_dotenv()
if not os.getenv("GOOGLE_API_KEY"):
raise ValueError("GOOGLE_API_KEY не найден. Пожалуйста, установите его в вашем .env файле.")
def main():
"""
Инициализирует и запускает AI команду для создания контента, используя новейшую модель Gemini.
"""
setup_environment()
# Определяем языковую модель для использования.
# Обновлено до модели из серии Gemini 2.0 для лучшей производительности и функций.
# Для передовых (preview) возможностей можно использовать "gemini-2.5-flash".
llm = ChatGoogleGenerativeAI(model="gemini-2.0-flash")
# Определяем агентов с специфическими ролями и целями
researcher = Agent(
role='Senior Research Analyst',
goal='Найти и резюмировать последние тренды в AI.',
backstory="Вы опытный исследовательский аналитик с талантом к выявлению ключевых трендов и синтезу информации.",
verbose=True,
allow_delegation=False,
)
writer = Agent(
role='Technical Content Writer',
goal='Написать четкий и привлекательный блог-пост на основе результатов исследования.',
backstory="Вы опытный писатель, который может переводить сложные технические темы в доступный контент.",
verbose=True,
allow_delegation=False,
)
# Определяем задачи для агентов
research_task = Task(
description="Исследовать топ-3 emerging тренда в Artificial Intelligence в 2024-2025. Сосредоточиться на практических применениях и потенциальном воздействии.",
expected_output="Детальное резюме топ-3 AI трендов, включая ключевые моменты и источники.",
agent=researcher,
)
writing_task = Task(
description="Написать 500-словный блог-пост на основе результатов исследования. Пост должен быть привлекательным и легким для понимания общей аудиторией.",
expected_output="Полный 500-словный блог-пост о последних AI трендах.",
agent=writer,
context=[research_task],
)
# Создаем Crew
blog_creation_crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential,
llm=llm,
verbose=2 # Устанавливаем verbosity для детальных логов выполнения команды
)
# Выполняем Crew
print("## Запуск команды создания блога с Gemini 2.0 Flash... ##")
try:
result = blog_creation_crew.kickoff()
print("\n------------------\n")
print("## Финальный результат команды ##")
print(result)
except Exception as e:
print(f"\nПроизошла неожиданная ошибка: {e}")
if __name__ == "__main__":
main()Теперь мы углубимся в дополнительные примеры в рамках фреймворка Google ADK, с особым акцентом на иерархические, параллельные и последовательные парадигмы координации, наряду с реализацией агента как операционального инструмента.
Практический код (Google ADK)
Следующий пример кода демонстрирует установление иерархической структуры агентов в рамках Google ADK через создание отношений родитель-потомок. Код определяет два типа агентов: LlmAgent и кастомный агент TaskExecutor, производный от BaseAgent. TaskExecutor разработан для специфических, не-LLM задач и в этом примере просто выдает событие "Task finished successfully". LlmAgent с именем greeter инициализируется с указанной моделью и инструкцией действовать как дружелюбный приветствующий. Кастомный TaskExecutor создается как task_doer. Родительский LlmAgent под названием coordinator создается также с моделью и инструкциями. Инструкции coordinator направляют его делегировать приветствия greeter'у и выполнение задач task_doer'у. Greeter и task_doer добавляются как под-агенты к coordinator'у, устанавливая отношения родитель-потомок. Код затем утверждает, что эти отношения правильно установлены. Наконец, он выводит сообщение, указывающее, что иерархия агентов была успешно создана.
from google.adk.agents import LlmAgent, BaseAgent
from google.adk.agents.invocation_context import InvocationContext
from google.adk.events import Event
from typing import AsyncGenerator
# Корректно реализуем кастомного агента, расширяя BaseAgent
class TaskExecutor(BaseAgent):
"""Специализированный агент с кастомным, не-LLM поведением."""
name: str = "TaskExecutor"
description: str = "Выполняет предопределенную задачу."
async def _run_async_impl(self, context: InvocationContext) -> AsyncGenerator[Event, None]:
"""Кастомная логика реализации для задачи."""
# Здесь была бы ваша кастомная логика.
# Для этого примера мы просто выдадим простое событие.
yield Event(author=self.name, content="Задача завершена успешно.")
# Определяем отдельных агентов с правильной инициализацией
# LlmAgent требует указания модели.
greeter = LlmAgent(
name="Greeter",
model="gemini-2.0-flash-exp",
instruction="Вы дружелюбный приветствующий."
)
task_doer = TaskExecutor() # Создаем экземпляр нашего конкретного кастомного агента
# Создаем родительского агента и назначаем его под-агентов
# Описание и инструкции родительского агента должны направлять его логику делегирования.
coordinator = LlmAgent(
name="Coordinator",
model="gemini-2.0-flash-exp",
description="Координатор, который может приветствовать пользователей и выполнять задачи.",
instruction="Когда просят поприветствовать, делегируй Greeter'у. Когда просят выполнить задачу, делегируй TaskExecutor'у.",
sub_agents=[
greeter,
task_doer
]
)
# Фреймворк ADK автоматически устанавливает отношения родитель-потомок.
# Эти утверждения пройдут, если проверить после инициализации.
assert greeter.parent_agent == coordinator
assert task_doer.parent_agent == coordinator
print("Иерархия агентов создана успешно.")Этот отрывок кода иллюстрирует использование LoopAgent в рамках фреймворка Google ADK для установления итеративных рабочих процессов. Код определяет двух агентов: ConditionChecker и ProcessingStep. ConditionChecker является кастомным агентом, который проверяет значение "status" в состоянии сессии. Если "status" равен "completed", ConditionChecker эскалирует событие для остановки цикла. В противном случае он выдает событие для продолжения цикла. ProcessingStep является LlmAgent, использующим модель "gemini-2.0-flash-exp". Его инструкция - выполнить задачу и установить "status" сессии в "completed", если это финальный шаг. LoopAgent с именем StatusPoller создается. StatusPoller настраивается с max_iterations=10. StatusPoller включает как ProcessingStep, так и экземпляр ConditionChecker как под-агентов. LoopAgent будет выполнять под-агентов последовательно до 10 итераций, останавливаясь, если ConditionChecker найдет, что статус "completed".
import asyncio
from typing import AsyncGenerator
from google.adk.agents import LoopAgent, LlmAgent, BaseAgent
from google.adk.events import Event, EventActions
from google.adk.agents.invocation_context import InvocationContext
# Лучшая практика: Определяем кастомных агентов как полные, самоописывающие классы.
class ConditionChecker(BaseAgent):
"""Кастомный агент, который проверяет статус 'completed' в состоянии сессии."""
name: str = "ConditionChecker"
description: str = "Проверяет, завершен ли процесс, и сигнализирует циклу остановиться."
async def _run_async_impl(
self, context: InvocationContext
) -> AsyncGenerator[Event, None]:
"""Проверяет состояние и выдает событие для продолжения или остановки цикла."""
status = context.session.state.get("status", "pending")
is_done = (status == "completed")
if is_done:
# Эскалируем для прекращения цикла, когда условие выполнено.
yield Event(author=self.name, actions=EventActions(escalate=True))
else:
# Выдаем простое событие для продолжения цикла.
yield Event(author=self.name, content="Условие не выполнено, продолжаем цикл.")
# Исправление: LlmAgent должен иметь модель и четкие инструкции.
process_step = LlmAgent(
name="ProcessingStep",
model="gemini-2.0-flash-exp",
instruction="Вы шаг в более длинном процессе. Выполните свою задачу. Если вы финальный шаг, обновите состояние сессии, установив 'status' в 'completed'."
)
# LoopAgent оркестрирует рабочий процесс.
poller = LoopAgent(
name="StatusPoller",
max_iterations=10,
sub_agents=[
process_step,
ConditionChecker() # Создаем экземпляр хорошо определенного кастомного агента.
]
)
# Этот poller теперь будет выполнять 'process_step'
# а затем 'ConditionChecker'
# повторно, пока статус не станет 'completed' или не пройдет 10 итераций.Этот отрывок кода объясняет паттерн SequentialAgent в рамках Google ADK, разработанный для построения линейных рабочих процессов. Этот код определяет последовательный конвейер агентов, используя библиотеку google.adk.agents. Конвейер состоит из двух агентов, step1 и step2. step1 называется "Step1_Fetch", и его результат будет сохранен в состоянии сессии под ключом "data". step2 называется "Step2_Process" и проинструктирован анализировать информацию, сохраненную в session.state["data"], и предоставить резюме. SequentialAgent с именем "MyPipeline" оркестрирует выполнение этих под-агентов. Когда конвейер запускается с начальным вводом, step1 выполнится первым. Ответ от step1 будет сохранен в состояние сессии под ключом "data". Впоследствии step2 выполнится, используя информацию, которую step1 поместил в состояние согласно его инструкции. Эта структура позволяет строить рабочие процессы, где результат одного агента становится вводом для следующего. Это общий паттерн при создании многошаговых AI или конвейеров обработки данных.
from google.adk.agents import SequentialAgent, Agent
# Результат этого агента будет сохранен в session.state["data"]
step1 = Agent(name="Step1_Fetch", output_key="data")
# Этот агент будет использовать данные от предыдущего шага.
# Мы инструктируем его, как найти и использовать эти данные.
step2 = Agent(
name="Step2_Process",
instruction="Проанализируйте информацию, найденную в state['data'], и предоставьте резюме."
)
pipeline = SequentialAgent(
name="MyPipeline",
sub_agents=[step1, step2]
)
# Когда конвейер запускается с начальным вводом, Step1 выполнится,
# его ответ будет сохранен в session.state["data"], и затем
# Step2 выполнится, используя информацию из состояния согласно инструкции.Следующий пример кода иллюстрирует паттерн ParallelAgent в рамках Google ADK, который облегчает параллельное выполнение множественных задач агентов. data_gatherer разработан для параллельного запуска двух под-агентов: weather_fetcher и news_fetcher. Агент weather_fetcher проинструктирован получить погоду для данного местоположения и сохранить результат в session.state["weather_data"]. Аналогично, агент news_fetcher проинструктирован получить топ новость для данной темы и сохранить её в session.state["news_data"]. Каждый под-агент настроен использовать модель "gemini-2.0-flash-exp". ParallelAgent оркестрирует выполнение этих под-агентов, позволяя им работать параллельно. Результаты от weather_fetcher и news_fetcher будут собраны и сохранены в состоянии сессии. Наконец, пример показывает, как получить доступ к собранным данным о погоде и новостях из final_state после завершения выполнения агента.
from google.adk.agents import Agent, ParallelAgent
# Лучше определить логику получения как инструменты для агентов
# Для простоты в этом примере мы встроим логику в инструкцию агента.
# В реальном сценарии вы бы использовали инструменты.
# Определяем отдельных агентов, которые будут работать параллельно
weather_fetcher = Agent(
name="weather_fetcher",
model="gemini-2.0-flash-exp",
instruction="Получите погоду для данного местоположения и верните только прогноз погоды.",
output_key="weather_data" # Результат будет сохранен в session.state["weather_data"]
)
news_fetcher = Agent(
name="news_fetcher",
model="gemini-2.0-flash-exp",
instruction="Получите топ новость для данной темы и верните только эту новость.",
output_key="news_data" # Результат будет сохранен в session.state["news_data"]
)
# Создаем ParallelAgent для оркестрации под-агентов
data_gatherer = ParallelAgent(
name="data_gatherer",
sub_agents=[
weather_fetcher,
news_fetcher
]
)Предоставленный сегмент кода иллюстрирует парадигму "Agent as a Tool" в рамках Google ADK, позволяющую агенту использовать возможности другого агента способом, аналогичным вызову функции. Конкретно, код определяет систему генерации изображений, используя классы LlmAgent и AgentTool от Google. Она состоит из двух агентов: родительского artist_agent и под-агента image_generator_agent. Функция generate_image является простым инструментом, который симулирует создание изображения, возвращая мок-данные изображения. image_generator_agent отвечает за использование этого инструмента на основе текстового промпта, который он получает. Роль artist_agent - сначала придумать креативный промпт для изображения. Затем он вызывает image_generator_agent через обертку AgentTool. AgentTool действует как мост, позволяя одному агенту использовать другого агента как инструмент. Когда artist_agent вызывает image_tool, AgentTool вызывает image_generator_agent с придуманным художником промптом. image_generator_agent затем использует функцию generate_image с этим промптом. Наконец, сгенерированное изображение (или мок-данные) возвращается обратно через агентов. Эта архитектура демонстрирует многослойную агентную систему, где агент высокого уровня оркестрирует специализированного агента низкого уровня для выполнения задачи.
from google.adk.agents import LlmAgent
from google.adk.tools import agent_tool
from google.genai import types
# 1. Простой функциональный инструмент для основной возможности.
# Это следует лучшей практике разделения действий от рассуждений.
def generate_image(prompt: str) -> dict:
"""
Генерирует изображение на основе текстового промпта.
Args:
prompt: Детальное описание изображения для генерации.
Returns:
Словарь со статусом и байтами сгенерированного изображения.
"""
print(f"ИНСТРУМЕНТ: Генерация изображения для промпта: '{prompt}'")
# В реальной реализации это вызывало бы API генерации изображений.
# Для этого примера мы возвращаем мок-данные изображения.
mock_image_bytes = b"mock_image_data_for_a_cat_wearing_a_hat"
return {
"status": "success",
# Инструмент возвращает сырые байты, агент обработает создание Part.
"image_bytes": mock_image_bytes,
"mime_type": "image/png"
}
# 2. Рефакторим ImageGeneratorAgent в LlmAgent.
# Теперь он корректно использует переданный ему ввод.
image_generator_agent = LlmAgent(
name="ImageGen",
model="gemini-2.0-flash",
description="Генерирует изображение на основе детального текстового промпта.",
instruction=(
"Вы специалист по генерации изображений. Ваша задача - взять запрос пользователя "
"и использовать инструмент `generate_image` для создания изображения. "
"Весь запрос пользователя должен быть использован как аргумент 'prompt' для инструмента. "
"После того как инструмент вернет байты изображения, вы ДОЛЖНЫ вывести изображение."
),
tools=[generate_image]
)
# 3. Оборачиваем исправленного агента в AgentTool.
# Описание здесь - это то, что видит родительский агент.
image_tool = agent_tool.AgentTool(
agent=image_generator_agent,
description="Используйте этот инструмент для генерации изображения. Ввод должен быть описательным промптом желаемого изображения."
)
# 4. Родительский агент остается неизменным. Его логика была корректной.
artist_agent = LlmAgent(
name="Artist",
model="gemini-2.0-flash",
instruction=(
"Вы креативный художник. Сначала придумайте креативный и описательный промпт для изображения. "
"Затем используйте инструмент `ImageGen` для генерации изображения, используя ваш промпт."
),
tools=[image_tool]
)Краткий обзор
Что: Сложные проблемы часто превышают возможности единственного монолитного агента на основе LLM. Одиночный агент может не обладать разнообразными специализированными навыками или доступом к специфическим инструментам, необходимым для решения всех частей многогранной задачи. Это ограничение создает узкое место, снижая общую эффективность и масштабируемость системы. В результате решение сложных многодоменных задач становится неэффективным и может привести к неполным или субоптимальным результатам.
Зачем: Паттерн Multi-Agent Collaboration предлагает стандартизированное решение путем создания системы множественных сотрудничающих агентов. Сложная проблема разбивается на меньшие, более управляемые подзадачи. Каждая подзадача затем назначается специализированному агенту с точными инструментами и возможностями, необходимыми для её решения. Эти агенты работают вместе через определенные протоколы коммуникации и модели взаимодействия, такие как последовательные передачи, параллельные потоки работ или иерархическое делегирование. Этот агентный распределенный подход создает синергетический эффект, позволяющий группе достигать результатов, которые были бы невозможны для любого отдельного агента.
Правило большого пальца: Используйте этот паттерн, когда задача слишком сложна для одного агента и может быть декомпозирована на отдельные подзадачи, требующие специализированных навыков или инструментов. Он идеален для проблем, которые выигрывают от разнообразной экспертизы, параллельной обработки или структурированного рабочего процесса с множественными стадиями, таких как комплексные исследования и анализ, разработка программного обеспечения или генерация креативного контента.
Визуальное резюме
Рис.3: Шаблон проектирования Multi-Agent
Ключевые выводы
- Multi-agent сотрудничество включает множественных агентов, работающих вместе для достижения общей цели.
- Этот паттерн использует специализированные роли, распределенные задачи и межагентную коммуникацию.
- Сотрудничество может принимать формы последовательных передач, параллельной обработки, дебатов или иерархических структур.
- Этот паттерн идеален для сложных проблем, требующих разнообразной экспертизы или множественных отдельных стадий.
Заключение
Эта глава исследовала паттерн Multi-Agent Collaboration, демонстрируя преимущества оркестрации множественных специализированных агентов в системах. Мы рассмотрели различные модели сотрудничества, подчеркивая существенную роль паттерна в решении сложных многогранных проблем в разнообразных доменах. Понимание агентного сотрудничества естественно ведет к исследованию их взаимодействий с внешней средой.
Ссылки
- Multi-Agent Collaboration Mechanisms: A Survey of LLMs
- Multi-Agent System — The Power of Collaboration
Навигация
Назад: Глава 6. Планирование
Вперед: [Глава 8. Управление памятью](../../Часть 2/Глава 8. Управление памятью.md)